This page gives more information on the webshop order messages and XSD schema's. This page will not explain what XSD files are, please use the Internet to find more information on XSD technology in general. Just a short notices about XSD's in general: We use XSD frequently to verify if the contents on an XML file meets certain criteria. Like for example are certain required fields available, and have certain fields correct values. So for example an Int32 field should not contain anything else as numerics. The big advantage of using XSD's is that RetailVista will not crash during the processing of invalid XML content, because the content has already been checked. Off course it's still possible that a message will be rejected during processing, because for example a barcode does not exist.

When building a webshop order integration, we strongly advice and encourage to use an XML/XSD validator. There are numerous online validators where you can submit your order XML and the corresponding XSD content. Such an online tool will verify the XML content and return if it's valid or not. It's exactly the same check as Retail3000 will do, so you can test your software upfront. It's even better to integate an XML/XSD check in your integration so you can decline your own order message even before sending it to RetailVista!

Every inbound message received in RetailVista will first be verified against the corresponding XSD schema. This is done based on the XSD reference in the header of an XML file, which refers an XSD schema name and version. If an xml message does not meet the XSD definitions, it will be rejected by Retail3000 with error messages describing the found problems.

Below we will give an explanation of all the fields in an XML order message which refers to the latest XSD version, which is currently version 1.3. In this example as many as possible fields are used, look at the XSD schema definition which fields are optional.

<?xml version="1.0" encoding="utf-8"?>
< Interchange version="1.3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:xmlns:nedfox-retaillink-com:WebOrder">
 <Envelope>
   <FromPartyNumber>9999999999999</FromPartyNumber> [When message is routed by RetailLink *1 a real partynumber should be used where the message came from. Under normal circumstances, use 13 times 9 to indicate a non-routable message]
   <FromPartyName>Webshop party</FromPartyName> [This is an explanation of the name of the 'FromPartyNumber' which can by any 'logic' name]
   <ToPartyNumber>9999999999999</ToPartyNumber> [When message is routed by RetailLink *1 a real partynumber should be used where the message is sent to. Under normale circumstances, use 13 times 9 to indicate a non-routable message]
   <ToPartyName>RetailVista</ToPartyName> [This is an explanation of the name of the 'ToPartyName' which can be any 'logic' name]
   <InterchangeReference>Int2018051700001</InterchangeReference> [This is an Interchange reference which should be unique on every transmission, especially when routed by RetailLink. Even sending the same order message twice, we expect different / unique interchange references. When RetailLink is not used, this field may be kept empty]
   <InterchangeDateTime>2018-05-17T12:41:30</InterchangeDateTime> [Date and time of Interchange when this message is sent to Retail3000]
   <InterchangeTest>false</InterchangeTest> [When true, this message is a test message and shouldn't be processed]
  </Envelope>
 <Messages>
  <Message>
   <MessageDateTime>2018-05-17T12:41:30</MessageDateTime> [Date and time of the webshop order message]
    <MessageReference>802</MessageReference> [Unique webshop order message. Can be left empty when not using RetailLink *1. Based on the content of this field, RetailLink can decide that this message has been received earlier and reject this message]
    <HighPriority>false</HighPriority>[Certain message types support priority like for example outgoing purchase orders. For webshop orders there is (yet) no specific support for high prio webshop orders]
    <Header>
    <SupplierPartyNumber>9999999999999</SupplierPartyNumber>  [When message is routed by RetailLink *1 a real partynumber should be used where the message came from. Under normal circumstances, use 13 times 9 to indicate a non-routable message]
    <BuyerPartyNumber>9999999999999</BuyerPartyNumber> [When message is routed by RetailLink *1 a real partynumber should be used where the message came from. Under normal circumstances, use 13 times 9 to indicate a non-routable message]
     <Customer>
     <CompanyName/> [Optional company name of the buyer]
      <FirstName>Mark</FirstName> [First name of the buyer]
     <MiddleName/> [Middlename of the buyer]
     <LastName>Vroom</LastName> [Last name of the buyer]
      <Address>
      <AttentionOf>Mark Vroom</AttentionOf> [Attention of as part of the customer address]
      <StreetName>Thuisadres straatnaam</StreetName> [Street name of the customer address]
      <StreetNumber>5</StreetNumber> [Street number of the customer address]
       <StreetNumberAddOn/> [Street number additional (like for example 'A' of '5A' of the street number]
       <ZipCode>8265AB</ZipCode> [ZipCode of the customer address]
       <State>Overijssel</State> [State of the customer address]
       <City>Zwolle</City> [City of the customer address]
      <CountryIsoCode>NL</CountryIsoCode> [Country ISO code of the country of the customer address]
     </Address>
     <LandlinePhoneNumber>038-123456</LandlinePhoneNumber> [Landline phonenumber of customer]
     <CellPhoneNumber>06-12345678</CellPhoneNumber> [Cellphone phonenumber of customer]
     <EmailAddress>dummy@nedfox.nl</EmailAddress> [Email address of customer]
    </Customer>
    <Delivery>
      <Name>NedFox B.V.</Name> [This is the name of the label for delivery]
     <Address>
      <AttentionOf>Woonboot</AttentionOf> [See address segment for information]
       <StreetName>Verlengde Gildenweg</StreetName> [See address segment for information]
       <StreetNumber>23</StreetNumber> [See address segment for information]
       <StreetNumberAddOn/> [See address segment for information]
       <ZipCode>8265TX</ZipCode> [See address segment for information]
       <State>Flevoland</State> [See address segment for information]
       <City>Emmeloord</City> [See address segment for information]
       <CountryIsoCode>NL</CountryIsoCode> [See address segment for information]
      </Address>
    </Delivery>
    <OrderDetails>
     <RequestedDeliveryDate>2018-05-11</RequestedDeliveryDate> [The requested delivery date by customer]
      <ExpectedDeliveryDate>2018-05-11</ExpectedDeliveryDate> [The expected delivery date as calculated by the webshop]
      <OrderDateTime>2018-05-11T12:41:30</OrderDateTime> [The order date and time when the order was created/finished]
      <OrderReference>2018.005.223</OrderReference> [The reference for this order as generated by the webshop]
      <ScenarioCode>TH</ScenarioCode> [The scenario in RetailVista to be used for processing this order]
      <CostCenterCode>1000</CostCenterCode> [The costcenter where this order needs to be assigned to]
      <FreeText>Levering graag na 12:00</FreeText> [Free text belonging to this order]
     </OrderDetails>
    <Transport> 
     <TypeDescription>PostNL</TypeDescription> [The selected transport type by the customer]
      <Properties>
      <Property>
       <Name>ProductOption</Name>
       <Value>118,006</Value>
      </Property>
      <Property>
       <Name>ProductOption</Name>
       <Value>120,004</Value>
      </Property>
     </Properties>
    </Transport>
    <Payments>
     <Payment>
      <Type>IDeal</Type> [The code of the used payment type to pay this order]
       <Value>4.95</Value> [The amount paid on this payment type]
       <DateTime>2018-05-11T12:41:30</DateTime> [The date & time of this payment]
       <Reference>Ideal20454233223-02</Reference> [The reference belonging to this payment]
      </Payment>
    </Payments>
   </Header>
   <Rows>
    <Row>
     <Barcode>
      <BarcodeValue>1234567890128</BarcodeValue> [The numeric barcode for the ordered product]
      </Barcode>
     <ProductDescription>Demo artikel omschrijving</ProductDescription> [The readable description of the ordered product]
     <SkuQuantity>1</SkuQuantity> [The number of ordered SKU's]
      <Price> 
      <GrossSalePriceInclVat>4.95</GrossSalePriceInclVat> [The normal gross sale price of the ordered product, including VAT]
       <NetSalePriceInclVat>3.95</NetSalePriceInclVat> [The net saleprice of the ordered product, including VAT]
       <SalePriceType>Sku</SalePriceType> [This indicates if the prices above are piece prices of prices for the ordered amount]
      </Price>
    </Row>
   </Rows>
   <Footer />
  </Message>
 </Messages>
< /Interchange>

*1 - RetailLink is the EDI communication platform of NedFox where EDI messages can be sent from and to. Messages can be sent to RetailLink by X400 and SMTP. When a message arrives from the outside world at RetailLink, it will be forwarded to RetailVista automatically. When integration based on RetailLink, the sending and receiving party should both have standardized and unique GS1 EDI partynumbers.